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Progress Report — Teaching of Procedures 
by Gerald Jay Sussman 

The idea of building a programmer is very seductive in that it 
holds the promise of massive bootstrapping and thus ties in with many 
ideas about learning and teaching* I will avoid going into those issues 
here. It is necessary, however, to explain what I am not working on, I am 
not interested in developing new and better languages for expressing 
algorithms. When FORTRAN was invented, it was touted as an automatic 
programmer, and indeed it was, as it relieved the user of complete 
specification of the details of implementation- Newer programming 
languages are just elaborations (usually better) of that basic idea. I 
am, however, interested in the problem of implementation of a Eortially 
specified algorithm rather than a complete algorithm and a partially 
specified implementation. This problem is truly in the domain of 

4 

Artificial Intelligence because the system which "solves" this problem 
needs a great deal of knowledge about the problem domain for which the 
algorithm is being constructed in order to "reasonably 11 complete the 
specification. Indeed, a programmer is not told exactly the algorithm 
to be implemented, he is told the problem which his program is expected 

to solve. 

A programmer hardly ever starts with no program at all. Usually, 
he has a program which is almost but not quite applicable to the need. In 
this case, the programmer determines how the given program is to be 
modified to display the desired behavior; he makes a patch. This 
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technique is closely related to debugging, in which a program designed to 
solve a known problem misbehaves in some case* The biy* Eust te understood 
wid a patch concocted* In general, under good conditions, the creation of 
8 program to solve some problea can to viewed as debugging an existing 
program* 

Thus, the purpose of thie project is to produce a "prorrammer. 1 * I 
Ha relying deeply on introspective concepts of how I do programming. 
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I, Automatic Program Construction 

I have been constructing a program called "HACKER" which writes 
and debugs programs in the BLOCKS world. It currently shows signs of 
life, writing some elementary programs fay debugging and patching. The 
program HACKER as well as the programs it operates on ar^ written in 
CONNIVER. 

The physics of the BLOCKS world is as follows: there are blocks 
on a table and a hand. The hand can lift only one blcck at a time. Kence 
the hand cannot lift a block if there are others on it* A block can only 
te placed on another if there is enough space on the other. Here we 
introduce one primitive which moves blocks in this world. (HJTON A B) 
puts block A on block B if A's top is clear and B has space for A on it, 
otherwise it produces an error. HACKfR does not consider the structure of 
FUTON just as I don't think about COWS. HACKER does, however, know about 
PUTOK and gets the error comments from it when it is incorrectly called. 
KACKER starts out with one well-commented but very limited program to 
work with: 

(IF-NEEDED I-F-ON ( IHFERATIVE-FOR (OK ! (X (ATOM !,X)) !<r (ATOM !,Y)))) 

(NEEX6 (AND (CLEARTOP ! f X) (SPACB-FOR ! f X !,*)) 

(PUTON X Y)) 
(ADIEU "OK)) 
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This program is called by pattern-directed invocation; if we need an 
imperative for petting atoaic object X (not a tower) on an atomic object 
\ t it is called. Its body consists of a call to FUTON coEraented by its 
prerequisites. The (ADIEU *0K) informs the caller of success. 

HACKER also knows: 

(IF-NEEDED M-O-CLEARTOP 

(KEAKING-OF (CLEARTOP ! *X) 

(NOT (EXISTS ! f (Y (GENSYM)) 

(OH !,I !,X))» 

(NOTE)) 

i.e. cleartop(x)=-n 3y .T. on(y,x) 

(IF-NEEDED S-F-KOT-OH 

(SUFFICES-FOR (NOT (ON ! 'X !'Y)) 
(EXISTS !,(2 (GENSXM)) 

(WHERE (ON ! t X !,Z) (NOT (= ! ,Z *,¥))))) 
(NOTE)) 

I.e. 3^y .}". on(x,z)=»— ion(x,y) 

"further concepts will be introduced as needed. In section II (Heuristic 
frofrasiEinft) we will deal with nore difficult concepts concerned with 



PAGE 5 



space. 



.Us talk to HACKER by asking it to achieve a desired final state, 
e.g. (ACHIEVE (OK A E)) or, say (ACHIEVE (AftD (01* A E) (ON B C)}). 
ACHIEVE first tests if its goal is already achieved and if so it returns 
OK. If not, it searches for a way to accoaplish the goal. 

Consider (ACHIEVE (OK AB)). If A has a clear top and there is 
space for A on B, then when I-F-ON is invoked, it calls (PUTOJi 'A 'B) 
which does the job. Suppose, however, the situation was: 



(OH A TABLE) 

(ON E TABLE) 
(ON C A) 





G 



I-F-ON is invoked, it calls PUTON. PUTON gets anfry and returns the error 
comment: 

UNSATISFIED PREREQUISITE (NOT (ON C A)) 
HACKER then backtraces, checking the truth of the comment (NEEDS (AND 
(CLEARTOP ,X) (SPACE-FOR ,X ,Y))...). It finds it untrue. Since this is a 
NEEDS comment, it writes code to achieve the prerequisites and patches it 
in. Now I-F-ON looks like this: 
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(IF-NEEDED I-F-ON ( IMPERATIVE-FOR (OK ! (X (ATOM ,X)) !(Y (ATOM ,1'))) 
(SETUP (CODE-FOR (AND (CLEARTOP !,X) (SPACB-FOR !,X !,Y)) 

(PROG "AUX- ((PROTECTEDS NIL)) 

(PROG (ACHIEVE (CLEARTOP !,X)) 

(PROTECT (CLEARTOP !,X))) 
(PROG (ACHIEVE (5PACE-F0R !,X !,Y)) 

(PROTECT (SPACE-FOR ! ,X ! f Y))) 
(UNPROTECT PROTECTEDS))) 
(PUTON X Y))) 

SETUP is a comment explaining the reasons for the code written; to setup 
for (PUTON X Y). CODE-FOR is a comment explaining that its second 
argument was written to achieve the first argument. The code written 
binds a variable PROTECTEDS and initializes it to NIL. It then achieves 
-<*rd protects each subgoal, unprotecting them before leaving. Protection 
Lb a mechanism for catching bugs of interaction between subgoals (to be 
explained later). 

This code was generated by a process I call pattern-directed 
nacre— expansion from a macro in HACKHt'S bag of coding tricks. (The 
concepts of a "bag of tricks" is due to Richard Greenhlatt). This trick 
is fairly complex and looks like: 
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(IF-NEEDED C-F-AND (CODE-FOR (AND . !'L) MOODE) 
"AUX" ((P NIL)) 
(FOR-EACH-ELEMENT G L 

(CSETQ P (CONS (LIST 'PROG (LIST 'ACHIEVE G) 

(LIST 'PROTECT G)) 

P)» 

(CSETQ CODE (APPEND '(PROG "AUX" ((PROTECTEDS NIL))) 

(REVERSE P) 

'((UNPROTECT PROTECTEDS)))) 
(NOTE)) 

The coaplexlty stems from the ability to code for AND of any number of 
elements. HACKER then backs up the stack and starts running from 
(SETUP...)- He gets to (ACHIEVE (CLEARTOP !,X)) before running into 
trouble. (CLEARTOP A) is not true so he looks for an imperative for 
cleartop. Not finding any he realizes it's tine to write some code. 
Finding M-O-CLEARTOP he sees that CLEARTOP is a defined concept and thus 
he writes, by pattern-directed macro-expansion: 

(IF-NEEDED (IMPERATIVE-FOR (CLEARTOP !X)) 
(HEANING-OF (CLEARTOP ! ,X) 

(ACHIEVE (NOT (EXISTS Z1 (ON Z1 !,X))))) 
(ADIEU 'OK)) 
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HACKER then runs the new imperative but he needs to achieve the not 
exists expression. It is not yet true, has no imperative, has no 
explicit meaning, but we have a trick for this case: 

(IF-NEEDED (CODE-FOR (NOT (EXISTS !V !'G)) 

(TOR-EACH !,V ! !G1 

(ACHIEVE (NOT !!G2)))) 
(CSETQ G1 (SUBST (LIST * f\ V) V G) 

G2 (SUBST (LIST '/\/ t V) V G)) 
(NOTE)) 

Thus we expand the ACHIEVE, patching to get: 

(IF-NEEDED (IMPERATIVE-TOR (CLEARTOP !X)) 
(MEANING-OF (CLEARTOP 1 ,X) 

(CODE-FOR (NOT (EXISTS Z1 (ON Z1 !»X))) 
(FOR-EACH Z1 (ON !Z1 ! ,X) 

(ACHIEVE (NOT (ON !,Z1 !,X)))))) 
(ADIEU 'OK)) 

FOR-EACH is a canned loop commonly found in CONNIVER programs. This code 
is run until it hits the expression (ACHIEVE (NOT (ON !,Z1 !,X)). Here 
we expand the macro S-F-NOT-CN getting: 
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(IP-NEEDED (IMPERATIVE -FOR (CLEARTOP !X)) 
(MEAKING-OF (CLEARTOP ! f X) 

(CODE-FOR (MOT (EXISTS Z1 (OK Z1 !,X))) 
(FOR-EACH Z1 (ON !Z1 !,X) 

(SUFFICES-FOR (NOT (ON !,Z1 !,X)) 
(ACHIEVE (EXISTS Z2 

(WHERE (ON !,Z1 !,Z2) 

(NOT (= ! f Z2 !,X)))))) 

(ADIEU 'OK)) 

We run this new code until we have to expend the expression (ACHIEVE 
(EXISTS -..))• Here we need the trick: 

(IF-KEEDED (CODE-FOR (EXISTS !V (WHERE ! 'C !'Q)) 
(FROG "AUX" (!,V) 

(CHOOSE !,V 1,Q (POSSIBLE !,G)) 

(ACHIEVE !,G))) 
(NOTE)) 

Thus we get: 
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(IF-NEEDED (IMPERATIVE-FOR (CLEARTOP !X)) 
(MEAKING-OF (CLEARTOP ! ,X) 

(CODE-FOR (NOT (EXISTS 21 (on Z1 !,X))) 
(FOR-EACK Z1 (ON !Z1 ! ( X) 

(SUFFICES-FOR (NOT (ON !,Z1 !,X)) 

(CODE-FOR (EXISTS Z2 (WHERE (ON ! ,Z1 ! ( Z2) 

(NOT (= !,Z2 !,X)))) 
(PROG M AUX" (22) 

(CHOOSE 22 (NOT (= ! f 22 !,X)) 

(POSSIBLE (ON ! t Z1 !,Z2))) 
(ACHIEVE (ON !,Z1 !,Z2)))))))) 
(ADIEU 'OK}) 

This code runs, CHOOSE (by magic of its own) makes Z2*TABLE. (ACHIEVE 
(ON C TABLE)) (reBember Z1=C) finds I-F-ON and calls it recursively, 
solving the problem. 

Note that by just running this specific example we got I-F-ON 
patched for situations where X is not CLEARTOP and a completely general 
CLEARTOP routine which not only solves this specific case but also any 
recursively or iteratively complex example. E.g« the performance program 
':an now, without modification, achieve (CLEARTOP A) in: 
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hote also that the knowledge used in writing this program is divided into 
two independent classes: 

1) Knowledge of the proglem domain: 
I-F-ON, M-O-CLEARTOP, S-F-NOT-ON 

2) Domain independent programing knowledge: 
i.e. all CODE-FOR methods. 

It is ay hope and honest belief f that almost all "programming" knowledge 
can fce coded into a snail number (perhaps 50) coding tricks, hew problem 
domain dependent knowledge can be easily added; for instance, 1 can 
define the concept of a 3-tower as: 

(IF-NEEDED (MEANING-OF (3-TOWER ! 'X |*X 1'Z) 

(AND (ON ! f X ! t Y) (ON ! t Y ! f Z)))) 
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II. Heuristic Programming 

So far ve have been dealing with well-defined and understood 
concepts like CLEARTOP (which even has an explicit definition), MOT- 
ONness (for which we have a sufficient condition) and ONness. The blocks 
world also contains a much fuzzier concept, SPACE-FOR, which we can not 
so clearly work out. For achieving CLEARTOP, there is only one program. 
Tjf it cannot do the 30b there is no hope. For SPACE-FOR, however, we have 

■rious strategies which can be tried, no one of which is guaranteed to 
work, nor is the failure of one an indication of ultimate failure. We now 
investigate the methods required to handle such concepts and the 
constructs which are entailed. 

Suppose that the scene is: 



(ON A TABLE) 
(ON B TABLE) 
(ON C B) 





nnd we want to put A on B. (CLEARTOP A) is true but we get stuck at 
(SPACE-FOR A B). Since it has no direct route to achieving the goal, 
HACKER looks around for a way to assign blame for this failure. Here we 
introduce a new set of facts. 
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( IF-NEEDED M-H-SPACE-FOR-1 

(HAY-HURT (SPACE-FOR ! 'X ! 'Y) (CLUTTERED !,Y)) 
(NOTE)) 

(IF-NEEDED K-O-CLUTTERED 

(MEAKING-OF (CLUTTERED ! 'X) 

(EXISTS !,<Y (GENSYM)) (WHERE (ON !,Y !,X) 

(NOT (PROTECTED (ON !,'/ !,X)))))) 
(NOTE)) 

(IF-NEEDED M-H-SPACE-FOR-2 

(MAY-HURT (SPACE-FOR !*X l 'Y) (HAPHAZARD !,Y)) 
(NOTE)) 

(IF-NEEDED H-O-HAPHAZARD 

(MEANING-OF (HAPHAZARD ! *X) 

(EXISTS !,(Y (GENSYM)) (WHERE (BADLY-PLACED ! t Y ! t X) 

(ON !,Y !,X)))) 
(NOTE) ) 

(IF-NEEDED C-F-NOT-WHERE 

(CODE-FOR (NOT (WHERE ! *X !*Y)) (ACHIEVE (NOT !,X))) 
(NOTE)) 
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These facts tell HACKER: 

1) Leek of space can be attributed to two possible causes; a 
cluttered surface or a hapha2ardly arranged surface. 

2) A surface is cluttered if it has on it objects which are not 
on it for a reason (if they were, the ONness relation would 
have been protected by the program which needs it preserved). 

3) A surface is HAPHAZARD if it is not packed, that is, if there 
are "badly placed" objects on it. 

"ACKER cones up with M-H-SPACE-POR-1 in searching for a blaaeful fact, he 
tests (CLUTTERED B) and finds it true. Thus he asigns it blame for the 
failure. Since this is an uncertain situation (as triggered by MAY-HURT) 

it gets compiled into a very special piece of code using a function 

5JTRATEGY-F0R. Also, since SPACE-FOR is a named concept (like CLEARTOP) we 
make an imperative for it: 

(IF-NEEDED (IMPERATIVE-FOR ( SPACE-FOR !X !Y)) 
(STRATEGY-FOR (SPACE-FOR !,X ! t Y) 

(ACHIEVE (NOT (CLUTTERED !,Y)))) 
(ADIEU 'OK)) 

This is then expanded (by straight pattern-directed ■acre-expansion as 
before) into: 
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(IP-WEEDED (IMPEKATIVE-FOR (SPACE-FOR !X !YJ) 
(STRATFCY-FOR (SPACE-TOR ! ,X !,Y) 
(KEANIKG-OF (NOT (CLUTTERED !,Y)) 

(COEE-FCR (NOT (EXISTS Y3 (VHERE (OK YJ !,X) 

(KOT (PROTECTED (OK Y3 !,X)))))) 
(TOR-EACH Y3 (WHERE (ON !Y3 !,X) 

(KOT (PROTECTED (OK !Y3 !,X)))) 
(SUFFICES-FOR (KOT (WHERE (OK !,Y3 I ,X) 

(KOT (PROTECTED (ON !,Y3 !,X))))) 
(ACHIEVE (KOT (OK | t l3 !,X)))))))) 
(ADIEU *OK)) 

Since (ACHIEVE (KOT (ON !,Y3 !,X))) is a problem already solved, this 
does it. STRATEGY-EOR is special in that it sets up an interrupt 
condition on its first argument being true. Thus if the situtation was: 
and the problem was (ACHIEVE (ON D C)) the FOR-EACH loop to get rid of A 
and E would not run to termination. As soon as A was removed (and put 
down on the table) control would return to STRATFGY-FOR because the 
(SPACE-FOR D C) would become true. 

I have not described yet how to use the HAPHAZARE concept! I 
leave that to the next section on debugging for an example. Note, 
however, that only a few new programming concepts, CODE-FOR-JiOT-WHFRE, 
KAY-HURT and STRATECY-FOR have been added in this section, but lots of 
new problem-domain concepts were introduced. 
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ill. Automatic Debugging 

Consider what will happen if we tell HACKER to (ACHIEVE (3-TOWER 
A B C)). He will write: 

(IE-HEEDED (IKPERATIVE-FOR (3-TOWER IX !Y IZ)) 
(MEANINC-OF (3-TOWER ! ( X ! ,Y ! t Z) 

(CODE-FOR (AND (ON !,X !,Y) (0« ! ,Y !,Z)) 
(PROG "AUX" ((PROTECTEDS NIX)) 
(PROG (ACHIEVE (ON !,X |,i)) 

(PROTECT (OH ! f X !,Y))) 
(PROG (ACHIEVE (ON ! ,X ! f Z)) 

(PROTECT (ON ?,x ! t Z))) 
(UNPROTECT PROTECTEDS)))) 
(ADIEU 'OK)) 

This program has a bug! The first clause of the (CODE-FOR (AND ...) ...) 
?ets A on B. The second tries to get 6 on C. First it tries to (CLEARTOP 
B) so B can be grasped. This forces an attempt to (PUTON A TABLE) but the 
first clause protected (ON A B) so A can't be moved. Thus we get the 
error comment from PUTON: PROTECTION VIOLATION (ON A B). At this point, 
HACKER is entered via a BUG routine called from PUTON with the error 
'.onment as its argument. From this vantage point HACKER looks up the 
:;tack to see if there are any alternatives to be considered. He reasons: 
I would have violated the protection by putting A anywhere; I had to put 
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A somewhere to get it off B. Even if I had another way to ret it off B I 
couldn't use it because the protection is on (OK A B). This restriction 
contradicts the meaning of (CLEARTOP B) and thus contradicts that goal. 
But (CLEARTOP B) is necessary to setup for (PUTON B C) so it doesn't help 
to try to achieve (SPACE-FOR B C) first, (a possible alternative — a 
PLANNER program would have tried it, and failed). Thus all of the aoves 
are forced from (ACHIEVE (ON B C)). This subgoal is thus inconsistent 
with the restriction; but it is necessary for the goal (AND (01* A B) (OH 
E C)) t but above this the restriction is gone. In fact, the restriction 
was placed in order to protect the previously achieved subgoal (OH A B). 
Thus we have no way to achieve those subgoals in the given order so I'll 
patch it so the offending step is before the offended one: 

(IF-NEEDED (IMPERATIVE-FOH (3-TOWER IX !Y !Z)) 
(MEANING-OF (3-TOWER l,X ! ,Y » ,Z) 

(CODE-FOR (AND (ON ! ,X ! ,Y) (OK' !,Y !,Z)) 
(PROG "AUX" ((PROTECTEES NIL)) 
(PROG (ACHIEVE (ON l w X !,Z)) 

(PROTECT (ON !,Y !,Z))) 
(PROG (ACHIEVE (ON ! t X !,Y)) 

(PROTECT (ON !,X !,Y))) 
(UHPROTECT PROTECTEDS)))) 
(ADIEU 'OK)) 
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This program is correct. But not all hues are so simple; let w. consider 
another: 

The situation is that all blocks (A, B, and C) are on the telle 
and the problem is: (ACHIEVE (U A B C)) where: 
(IP-NEEDED (MEANING-GF (U ! 'X 1*1 ! 'Z) 

(AND (Oli !,X !,Z) (OK !,Y !,Z))) 
(KOTE)) 

Tn this case the code generated is: 

(IF-KEEDED (IMPERATIVE-FOR (U !X !Y !Z)) 
(WEANTNG-CF (U !,X !,Y 1,2) 

(COD&-FOR (AND (OK ! ,X !,Z) (OK !,¥ !,Z)J 
(PROG "AUX M ((PROTECTEES NIL)) 
(PROG (ACHIEVE (ON !,X !,Z)) 

(PROTECT (ON !,X !,Z))) 
(PROC (ACHIEVE (ON !,Y ! f Z)) 

(PROTECT (ON l t i !,Z))) 
(UNPKOTECT PROTECTEES)))) 
(ADIEU 'OK)) 

This code is nearly CK, but when we execute (ACHIEVE-(ON A C)) A goes on 
Lhe Diddle of C (a heuristic to uaxicize stability). Thin blookr the 
(SPACE-FOR E C) becuase C isn't large enough to hold B with A on its 
Kiddle. Vhat does HACKER do? The performance progran is in (STRATEGX-TOr 
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(3PACE-F0R B C) ... ) when it discovers that it cannct win by the clutter 
strategy as (ON A C) is protected. Since there are no other strcUertes 
currently coded, STRATEGY-FOP. asks HACKEE for help. HACXIJt finds another 
strategy, M-K-SPACE-FOR-2; the HAPHAZARD strategy, and finds, indeed, 
that (HAPHAZARD C) is true. This is then coded up as before as an 
alternative strategy: (from now on I will leave out details of expansion, 
filling in with ... and only showing relevant segments.) 

(STRATEGY-FOR (SPACE-FOR ! ,X !,Y) 

(MEANIKG-QF (KOT (CLUTTERED !,i)) ... ) 
(MEAHTNG-OF (KOT (HAPHAZARD !,*)) ... )) 

This code indeed solves the problem but we must introduce sooe more 
primitives. 

(IF-KEEDED (INPERATIVE-FOR (PACKED !X !Y)) 
(KEEDS (CLEARTOP !,X> (PACK X Y)) 
(ADIEU 'OK)) 



(IE-KEEDED (SUFFICES-FOR (NOT (BADLY-PLACED t 'X !'Y)) (PACKET !,X r,Y)) 
(NOTE)) 

Note: STRATEGY-FOR takes any nuniber of strategies and exhausts them in 
the given order. 
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Note: PACK pushes its first argument as far as it can from the center of 
its second argmrent, without falling off. 

This patch, though it works in this case, arid is often useful, ir 
not a good patch. In fact, HACKER realizes the trouble quickly. We see 
that in running the patch, A is pushed to a corner of C. But A was the 
last object moved, (HACKER keeps a record of this) and if an object is 
moved twice with no intervening other manipulations, it should iu;ve been 
moved to the correct place the first time. This is not just a matter of 
efficiency — if the problem had been: (AND (OH A C) (ON D A) (Oi; E C) 
(OH E B)) we would have had trouble pushing the towers (p A) or (E B). 
Though there is a permutation of the AND which will work, the problem is 
compounded with compound objects (not yet discussed) as in (AND (OH 
(TOWER D A) C) (ON (TOWFK E B) C)). In any case, HACKER has an eye 
peeled (an interrupt set) for double movements in execution of a single 
command. He allows the execution to proceed but leaves a note to hinself 
to investigate the problem when the command returns successfully. Each 
tine an object is moved, the "physics" leaves a note on the HISTORY list 
with the activation of the mover. Thus when the program successfully 
returns HACKER sees that the first mover of A was: 
(PUTON A C) called by (ACHIEVE (ON A C)) 

and that the second was: (PACK A C) which left A in a good position. 
Thus he edits the first goal to reads (ACHIEVE (ON A C PACK)) which will 
put it down packed the first time (I lied to you about I-F-QH and PUTON: 
they really have an optional position defining argument whose default is 
"center 11 ). 
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The DEBUGGING knowledge appearing in this section is not as 
explicitly stated as in the proceeding sections because it ic not yot 
coded* A major criterion for the code is that it break up into STOCKS and 
programming knowledge. 



